Sadly, this app is suppose to go live tomorrow, so I am now limited in
terms of what sort of experiments I can do. But I'd like to re-use this
code in future projects, so I would like to figure this problem out.
Does anyone think (wrap-files) would be more reliable than
(wrap-resources)?
On Wednesday, February 6, 2013 11:17:03 AM UTC-5, larry google groups wrote:
>
> I hit the app itself with Apache Benchmark. The speed is fairly bad. This
> is a small app which serves everything from memory -- there is no database
> to slow things down. I am aware that I made several mistakes with this app.
> I had to write it in a huge hurry. I abused the Enlive template system and,
> I am fairly sure, there are places where I redundantly change Enlive nodes
> to a string, then change them back to Enlive nodes, then change them back
> to a string to serve them to the public. I imagine I can get a speed bump
> when I go back through and clean it up. But I am still left with the main
> puzzle: why does the CSS sometimes fail to load? I know that sometimes
> (rarely) if I point my browser directly at the path for the CSS file, I get
> a 404 error. What would cause an intermittent problem like that? Some
> background exception? What?
>
> ab -n 1000 -c 10
>
> Server Software: Jetty(7.x.y-SNAPSHOT)
> Document Path: /
> Document Length: 4277 bytes
>
> Concurrency Level: 10
> Time taken for tests: 235.877 seconds
> Complete requests: 1000
> Failed requests: 0
> Write errors: 0
> Total transferred: 4551891 bytes
> HTML transferred: 4277000 bytes
> Requests per second: 4.24 [#/sec] (mean)
> Time per request: 2358.775 [ms] (mean)
> Time per request: 235.877 [ms] (mean, across all concurrent requests)
> Transfer rate: 18.85 [Kbytes/sec] received
>
> Connection Times (ms)
> min mean[+/-sd] median max
> Connect: 137 139 3.4 138 172
> Processing: 1372 2216 280.3 2210 3057
> Waiting: 1371 2215 280.3 2210 3057
> Total: 1510 2355 280.5 2351 3195
>
> Percentage of the requests served within a certain time (ms)
> 50% 2351
> 66% 2470
> 75% 2558
> 80% 2610
> 90% 2734
> 95% 2828
> 98% 2914
> 99% 3008
> 100% 3195 (longest request)
>
>
>
>
>
>
> On Wednesday, February 6, 2013 10:53:50 AM UTC-5, larry google groups
> wrote:
>>
>> I logged into my personal server (in the Rackspace cloud, what used to be
>> Slicehost) and blasted the CSS file with 10,000 requests. There were 0
>> (zero) failed requests. This is with Apache Benchmark ("ab -n 10000 -c
>> 50"). The server, Jetty, was able to serve the CSS 10,000 times, yet it
>> fails on occasion when my co-workers go and look at it. I am struggling to
>> think what the problem is. Any suggestions? Does Jetty fail when the app is
>> running an activity in something other than the main thread?
>>
>>
>> Document Path: /css/timeout.css
>>
>> Document Length: 3688 bytes
>>
>>
>> Concurrency Level: 50
>>
>> Time taken for tests: 62.913 seconds
>>
>> Complete requests: 10000
>>
>> Failed requests: 0
>>
>> Write errors: 0
>>
>> Total transferred: 38430000 bytes
>>
>> HTML transferred: 36880000 bytes
>>
>> Requests per second: 158.95 [#/sec] (mean)
>>
>> Time per request: 314.563 [ms] (mean)
>>
>> Time per request: 6.291 [ms] (mean, across all concurrent requests)
>>
>> Transfer rate: 596.53 [Kbytes/sec] received
>>
>>
>> Connection Times (ms)
>>
>> min mean[+/-sd] median max
>>
>> Connect: 137 154 75.0 143 1241
>>
>> Processing: 139 160 39.0 152 772
>>
>> Waiting: 138 160 38.0 152 663
>>
>> Total: 277 314 86.6 298 1636
>>
>>
>> Percentage of the requests served within a certain time (ms)
>>
>> 50% 298
>>
>> 66% 306
>>
>> 75% 313
>>
>> 80% 318
>>
>> 90% 341
>>
>> 95% 363
>>
>> 98% 422
>>
>> 99% 680
>>
>> 100% 1636 (longest request)
>>
>>
>>
>>
>>
>>
>> On Wednesday, February 6, 2013 10:10:25 AM UTC-5, larry google groups
>> wrote:
>>>
>>>
>>> I created a web app using Ring, Jetty, Enlive, Compojure.
>>>
>>> At the end, I bundled everything together by running the command "lein
>>> uberjar". The resulting file was 21 megs.
>>>
>>> I scp the file to the server, then I ssh to the server. I start a
>>> "screen" session. Inside the screen session I type :
>>>
>>> java -jar kiosk-0.1-standalone.jar 30001
>>>
>>> The number at the end is the port that I have it running on.
>>>
>>> Sometimes, when people look at the app, none of the CSS files load. I
>>> have run into this bug myself. Sometimes, when I look at the app, the
>>> Javascript and CSS paths are broken. If I click "view source" and see the
>>> source, and if I try to follow the links to the CSS or Javascript, then I
>>> get 404 errors.
>>>
>>> I have this in my code:
>>>
>>> (wrap-resource "public")
>>>
>>> The structure of the code is:
>>>
>>> /resources
>>> /public
>>> /css
>>> /javascript
>>> /templates
>>> /src
>>> /kiosk
>>>
>>> The code is still able to find the templates in resources/templates, and
>>> that HTML is given to Enlive, so something appears on screen. It's just the
>>> stuff in "public" that sometimes goes missing.
>>>
>>> Can anyone suggest why? My routes are defined like this:
>>>
>>>
>>> (defroutes app-routes
>>> (ANY "/" request (index request))
>>> (GET "/search-results" request (search-results request))
>>> (GET "/schema" [] (schema))
>>> (GET "/account" request (account request))
>>> (GET "/login" request (login request))
>>> (GET "/start-over" request (start-over request))
>>> (GET "/admin" request (admin request))
>>> (GET "/ok" request (ok request))
>>> (POST "/admin" request (record-new-question-if-any request))
>>> (GET "/delete-question/:question-to-delete" request (delete-question
>>> request))
>>> (GET "/finish-user-sign-up" request (finish-user-sign-up request))
>>> (route/not-found "Page not found"))
>>>
>>> (def app
>>> (-> app-routes
>>> (wrap-resource "public")
>>> (wrap-session {:cookie-name "discovery-session" :cookie-attrs
>>> {:max-age 90 }})
>>> (wrap-cookies)
>>> (wrap-keyword-params)
>>> (wrap-nested-params)
>>> (wrap-params)))
>>>
>>>
>>>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
