Pharo Success Story: Reflex Vacances

Hi,

Added to the page
        http://www.pharo-project.org/about/success-stories


Reflex Vacances
=============
Reflex Vacances is a website to rent holiday homes all over France.

The website lists 2000+ houses, and it runs 100% in Pharo + Iliad + MongoDB.

"Cette plateforme regroupe des milliers d'annonces publiées par des
 propriétaires de toute la France, tous spécialistes de la location de
vacances. Nous l'avons dotée d'un logiciel sur mesure développé
pour permettre à la fois aux visiteurs de juger de la qualité des
annonces et aux propriétaires de valoriser grâce à un espace
optimisé ou le logement peut-être abondamment décrit."

Contact http://www.objectfusion.fr for more information.

Very nice !

And it is fast.

Great work.

Sven

On 29 Jan 2014, at 13:30, Marcus Denker <[hidden email]> wrote:



--
Sven Van Caekenberghe
Proudly supporting Pharo
http://pharo.org
http://association.pharo.org
http://consortium.pharo.org

2014-01-29 Sven Van Caekenberghe <[hidden email]>:
> Very nice !

+1

> And it is fast.

This surprised me too. I was expecting a Zinc server somewhere, but it
uses Kom, so the speed must come from Illiad.

Regards!


Esteban A. Maringolo

On 29 Jan 2014, at 13:39, Esteban A. Maringolo <[hidden email]> wrote:

> 2014-01-29 Sven Van Caekenberghe <[hidden email]>:
>> Very nice !
>
> +1
>
>> And it is fast.
>
> This surprised me too. I was expecting a Zinc server somewhere, but it
> uses Kom, so the speed must come from Illiad.

I think the speed comes from knowing very well what you are doing and optimising the right things, probably lots of caching on different levels ;-)

> Regards!
>
>
> Esteban A. Maringolo
>

2014-01-29 Sven Van Caekenberghe <[hidden email]>:
That is totally true.

But still... sometimes the tools used impose a minimum (or maximum)
performance, memory requirements, etc.
E.g. I'm considering moving away from Seaside-REST to bare Zinc
delegators. But that's a topic for other story. :)










Esteban A. Maringolo

> runs 100% in Pharo + Iliad + MongoDB.

"Look ma - no apache or nginx".

According to responses it runs "KomHttpServer/7.1.3 (unix)". Also for
resources like images. And it is fast.
 
Would be interesting to know more about the architecture, speed of
machine, optimizations done, ...

Anyone know more about it and able to share some insights.

Thx
T.

Torsten Bergmann writes:

>> runs 100% in Pharo + Iliad + MongoDB.
>
> "Look ma - no apache or nginx".

Hi!

Apache is used as a frontend server, and many images are indeed in the
db, thus served through Pharo.

The Pharo image is a 1.4, the VM is Cog, with a typical Mongo+Voyage
setup. Most of the DB data is cached by Voyage, which partly explains
the speed.

Mongo and Pharo are running on the same machine, there's no special
caching except for what Voyage provides by default.

The Iliad app is served by Kom, and we have many bash scripts to monitor,
auto-restart and manage the app (we manage SmalltalkHub in a similar
way).

Cheers,
Nico


--
Nicolas Petton
http://nicolas-petton.fr

Norbert Hartl wrote:

Am 29.01.2014 um 16:49 schrieb Esteban A. Maringolo <[hidden email]>:

2014-01-29 Sven Van Caekenberghe <[hidden email]>:

On 29 Jan 2014, at 13:39, Esteban A. Maringolo <[hidden email]> wrote:

2014-01-29 Sven Van Caekenberghe <[hidden email]>:

Very nice !

+1

And it is fast.

This surprised me too. I was expecting a Zinc server somewhere, but it
uses Kom, so the speed must come from Illiad.

I think the speed comes from knowing very well what you are doing and optimising the right things, probably lots of caching on different levels ;-)

That is totally true.

But still... sometimes the tools used impose a minimum (or maximum)
performance, memory requirements, etc.
E.g. I'm considering moving away from Seaside-REST to bare Zinc
delegators. But that's a topic for other story. :)

Exactly what I did the last weeks :)

The whys-and-how-fors of that might make a good blog post somewhere.  I'd like to know what a "bare Zinc delegator" is.
cheers -ben

Norbert

Ben,

On 30 Jan 2014, at 14:33, [hidden email] wrote:

> I'd like to know what a "bare Zinc delegator" is.

He refers to Zinc-REST, an optional micro framework on top of Zinc HTTP Components. This is loadable as group 'REST' from ConfigurationOfZincHTTPComponents.

You create subclasses under ZnRestCall, ZnAutoMatchedRestCall or ZnJSONRestCall and implement #get, #put, #post and/or #delete methods for each resource endpoint.

The framework offers dispatching (routing) and some conversions and conveniences, but you can basically do what you want.

Check out the unit tests.

Sven

Sven Van Caekenberghe wrote:

Ben,

On 30 Jan 2014, at 14:33, [hidden email] wrote:

  

I'd like to know what a "bare Zinc delegator" is.
    

He refers to Zinc-REST, an optional micro framework on top of Zinc HTTP Components. This is loadable as group 'REST' from ConfigurationOfZincHTTPComponents.

You create subclasses under ZnRestCall, ZnAutoMatchedRestCall or ZnJSONRestCall and implement #get, #put, #post and/or #delete methods for each resource endpoint.

The framework offers dispatching (routing) and some conversions and conveniences, but you can basically do what you want.

Check out the unit tests.

Sven 

  

Thanks Sven.